home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-pip-ipit-transition-00.txt
< prev
next >
Wrap
Text File
|
1993-07-08
|
40KB
|
983 lines
Pip Working Group P. Francis
INTERNET-DRAFT (formerly Tsuchiya)
Bellcore
July 1993
IP Independent Transition (IPIT) for Pip
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts).
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
Abstract
This document outlines a transition scheme for moving from IP to Pip.
While this document discusses Pip in particular, it could be applied
to any IPng. The transition scheme discussed here is called IPIT,
for IP Independent Transition. It has been developed to address
problems with the IPAE transition scheme, after which the previous
Pip transition scheme was based.
The shortcomings of IPAE stem from its reliance on IP addresses dur-
ing the first phases of transition. The result is that IP-only hosts
will not be able to talk globally to IPng hosts after IP addresses
have depleted (they will only be able to talk intra-domain). IPIT
allows new Pip systems to talk to IP systems without a globally
unique IP address. As a result, IP address depletion is less likely
with IPIT, and IP-only hosts will be able to talk to Pip hosts for-
ever. In this sense, IPIT is as much a co-existence scheme as it is
a transition scheme.
Pip WG, Expires February 1, 1994 [Page 1]
INTERNET-DRAFT Pip Transition July 1993
1. Problems with IPAE
I have increasing concerns about IPAE-style transition. There are
some aspects of it that are bad for Pip in particular, but I also
have a general concern. That is, for ubiquitous global packet
exchange, the transition requires that the large majority of systems
are IPng systems at the point in time when IP addresses are no longer
unique. When IP addresses are no longer unique, then IPng systems,
at least for the purpose of inter-domain communications, are config-
ured without globally unique IP addresses. Without a globally unique
IP address, an IPng system cannot talk to an IP-only systems in other
domains, because the IP-only system has no way to uniquely identify
the IP-only system [1].
If there are very few IP-only systems by the time IP addresses are no
longer unique, then the problem is not so bad. I am concerned, how-
ever, that it will take the community a very long time to really
install IPng. Even with address depletion as a motivating factor
towards IPng, it may be that users will choose to do NAT or address
reuse rather than install IPng.
I am also concerned that the need for IP address assignments in new
systems will do nothing to slow the depletion of IP addresses.
IPAE-style transition additionally has some bad ramifications for Pip
specifically. Having to assign IP addresses to Pip hosts constrains
them in several ways. First, the auto-address configuration feature
of Pip is less advantageous if an IP address must be manually
assigned to the host. Plug-and-play operation is lost.
Second, the IPAE scheme implies that packets from an IP host to a Pip
host are routed via IP until they happen to reach a Pip router. When
the infrastructure is still primarily IP (with a Pip overlay), this
will mean that IP packets from IP hosts will travel as IP for most of
the path, and are therefore subject to the same limitations as IP.
This manifests itself as limiting mobility and limiting provider
selection. In our Columbus demo, we realized that we could only
achieve one-direction provider selection with IPAE, because the
return packets would take the IP path regardless of the path taken by
the forward (Pip) packet. When considering demo'ing mobility for the
Amsterdam demo, we discovered that the movement from one LAN to
another would require a new IP address, and therefore a new Pip ID.
Thus, mobility in Pip over the near term is only as good as mobility
with IP, which is not very good.
Pip WG, Expires February 1, 1994 [Page 2]
INTERNET-DRAFT Pip Transition July 1993
So, for all of the above reasons, I am beginning to favor a transi-
tion scheme that does not require an IP address in the Pip header. I
call the scheme IP Independent Transition, or IPIT. IPIT is more
complex algorithmically than IPAE, but I think it is not overly com-
plex. In any event, IPIT has the advantage of immediately freeing
Pip from the constraints and limitations of IP.
2. Description of IPIT
IPIT has the following characteristics:
1. Pip hosts do not need IP addresses embedded in them. (By-and-
large this document assumes that Pip is the IPng being transi-
tioned to. However, IPIT can be applied to any IPng transition
scheme.)
2. Unlike IPAE, IPIT potentially allows IP hosts to remain IP for-
ever, without losing the ability to communicate directly with
all other hosts, either IP or IPng. I say potentially because
this is only possible as long as the number of IP-only hosts is
small enough that IP address depletion doesn't occur. Since
IPng hosts don't require IP addresses, however, this happen-
stance is a distinct possibility. In this sense, IPIT is as
much a co-existence scheme as it is a transition scheme.
3. In general, packet translation takes place as close to the IP
host as possible, but at distinct locations, usually a router on
the subnet of the host or a router at the border of the host's
routing domain. (Putting them in these distinct locations sim-
plifies discovery of translating routers.) The exceptions to
this are for intra-domain traffic, where translation can take
place at the Pip host (meaning that IP packets come from the Pip
host), or, in the case of a packet between two IP hosts without
an IP path between them, at whatever Pip routers are closest to
the hosts. Pip/IP translating routers are called XRs.
4. If communications is between two IP hosts, and there is an IP
infrastructure between them, then the packet remains IP
throughout (is not translated to Pip).
5. XRs maintain a pool of IP addresses. (Before you get all
excited, note that this is *not* a NAT scheme, or, at least,
does not have any of the ugly characteristics of what has become
Pip WG, Expires February 1, 1994 [Page 3]
INTERNET-DRAFT Pip Transition July 1993
known as NAT schemes [1].) In particular, no modification of
checksums are necessary, and the location and choice of XRs are
such that the pool of addresses is large enough to not require
frequent re-assignment.
IP addresses from the pool are mapped to Pip hosts. XRs
translate from IP to Pip by indexing the translation table with
the destination IP address (which has been assigned from the
pool). XRs translate from Pip to IP by indexing the translation
table with the source Pip ID.
6. Pip hosts are aware of the pool IP address assigned to them, and
use it to calculate the TCP pseudo-header checksum. Thus, the
translation at the XR is efficient (on the order of the cost of
the IPAE translation).
7. Except for the case of inter-domain packet exchange between two
IP hosts across a Pip infra-structure, the assignment of pool IP
addresses are made before any internet data packets are
transmitted. The assignments are made during DNS lookup. Thus,
translating routers generally do not need to make queries them-
selves.
2.1. Managing Pools of IP Addresses
One concern with the use of pools of IP addresses assigned to Pip
hosts is that the dynamics of assignment will result in incorrect
translations--that is, IP hosts will remember an assignment after it
has been reassigned, and try to use it. Another concern is that the
pools will have to be large (to satisfy the first concern), and thus
IP address exhaustion will be exacerbated. These concerns are
addressed here.
As mentioned above, translation generally takes place 1) at the sub-
net of the IP host, 2) at the border of the IP domain, and 3) at the
border of or within the Pip domain.
If translation takes place at the border of the Pip domain, then it
means that the backbone infrastructure is still capable of routing
IP. The destination IP address, which comes from the XR's pool, will
route the packet over the backbone infrastructure to the XR. This IP
address must therefore be globally unique.
Pip WG, Expires February 1, 1994 [Page 4]
INTERNET-DRAFT Pip Transition July 1993
In this case, the XR only needs to maintain translations for the Pip
hosts in the Pip domain. Thus, at most, the pool need be only as
large as the number of Pip hosts in that domain. With IPAE, the Pip
hosts would need an IP address anyway, so stocking the XR with one IP
address for every Pip hosts uses no more IP addresses than IPAE.
Furthermore, the IP addresses in the pool can be assigned flat (no
subnetting). So, in fact, the number of IP addresses needed, even if
there is one for every Pip host, is smaller than with IPAE.
In addition, it is probably reasonable in many if not most cases for
the number of IP addresses in the pool to be smaller than the number
of Pip hosts, as usually most hosts in a private network do not
directly exchange packets with hosts outside the domain. Thus, in
most cases, fewer IP addresses than there are Pip hosts will be
required.
If the XR is at the IP domain's border or at the IP host's subnet,
then the packet will cross the backbone infrastructure as a Pip
packet. Intra-domain IP routing will route the packet to the XR.
Since the IP packet never reaches the backbone infrastructure, the
destination IP address (from the XR's pool) need not be globally
unique. Therefore, the pool of IP addresses can come from a reused
class A network number. The XR therefore has a pool of over
16,000,000 IP addresses from which to make assignments. These could
be subdivided across individual XR's in the IP domain, or each XR in
the IP domain could have the full class A, for use on it's attached
subnets.
At the same time, the number of Pip hosts for which assignments
potentially have to be made is large--all Pip hosts. But, with such
a large pool, an old assignment could be stale for a long time before
it is flushed. (In this case, the memory needed to hold the assign-
ments, not the number of assignments available, becomes the
bottleneck.)
To reiterate, early in transition, when the backbone is still IP,
there will be a relatively small number of Pip hosts, and therefore a
relatively small number of IP addresses required for XR pools. Later
in transition, when the backbone is Pip (though there may still be
millions of IP hosts), translation will take place at IP-domain bord-
ers or within the IP domain, and XR pool addresses can come from a
reused Class A network number.
Pip WG, Expires February 1, 1994 [Page 5]
INTERNET-DRAFT Pip Transition July 1993
2.2. Phases of Transition
There is only one major "phase" in the IPIT transition scheme. That
is the point at which IP forwarding is disabled in the provider net-
works. Up until that point, IPIT transition takes place piece-meal.
For IP forwarding to be disabled in provider networks, all domains
must have an XR at the border. By definition, if all provider net-
works are able to forward Pip packets, then all domains have an XR at
the border--the provider's Pip router is that XR. Thus, once all
providers move over to Pip, IP can be turned off in the backbones.
There is one clear benefit that results from reaching this phase in
the transition. That is, XRs no longer need to have globally unique
IP addresses in their pools. As discussed above, an XR pool IP
address need only be globally unique when the translation is taking
place at the XR bordering the Pip system. Once all IP domains have
XRs, there is no longer a need for these globally unique IP
addresses. Therefore, all remaining IP addresses can be devoted to
true IP hosts.
This means that, if at some point we are in danger of IP address
depletion, a program of Pip (or some IPng) installation in backbones
(or, at least, XR installation at all borders) can be undertaken.
While it would be unfortunate to have to "artificially" mandate the
installation of any given protocol "before its time", it at least
seems feasible to mandate such a thing in provider networks, which
represents a small minority of systems globally, and have adequate
knowhow for such an installation.
Of course, even if this phase of installation is reached, it is pos-
sible for address depletion to occur--if too many hosts are installed
as IP only. In this case, an IP address re-use must be used. This
means either that some IP systems will not be able to communicate
globally (only internally), or that a NAT scheme must be employed.
Other than the potential need for pushing providers towards Pip, all
other installation of Pip can happen naturally. The following para-
graphs discuss the requirements for installing Pip systems.
In theory, it is possible to install any Pip host any time anywhere
in the internet. In practice, however, it is useful to have some
amount of Pip infrastructure in place to simplify installation of Pip
hosts.
Pip WG, Expires February 1, 1994 [Page 6]
INTERNET-DRAFT Pip Transition July 1993
2.3. Translation in More Detail
Assume that XR has a Pip ID = XPID and a Pip address = XPA. Assume
that the XR has assigned an IP address XIP from its pool to a Pip
host with ID = HPID, and Pip address = HPA. One or more IP hosts may
be exchanging packets with the Pip host using XIP. Assume that the
IP addresses of the IP hosts that are exchanging packets are IP1,
IP2, and so on. The XR has a translation table that maps XIP into
HPID/HPA and maps HPID into XIP.
When a packet arrives at XR from IP host with address IP1, the source
IP address (sa) is IP1 and the destination IP address (da) is XIP
(sa=IP1, da=XIP).
XR indexes the translation table with XIP and retrieves HPID and HPA
Using this information, it translates this into a Pip packet with a
source Pip ID (spid) that contains the IP hosts address IP1, the des-
tination Pip ID (dpid) of the Pip host HPID, the source Pip address
(spa) of itself XPA, and the destination Pip Address (dpa) of the Pip
host HPA (spid = IP1, dpid = HPID, spa = XPA, dpa = HPA).
Thus, the translation is
<sa=IP1, da=XIP> -X-> <spid=IP1, dpid=HPID, spa=XPA, dpa=HPA>
where the symbol -X-> means translation.
Note that the IP host's address IP1 never entered into the lookup
process. It was just copied from the source IP address into the
source Pip ID. Thus, a packet from IP2 to the same Pip host would
use the same translation table entry:
<sa=IP2, da=XIP> -X-> <spid=IP2, dpid=HPID, spa=XPA, dpa=HPA>
When a packet from the Pip host back to IP1 is received at XR, it
uses the Pip host's Pip ID HPID to index the translation table and
retrieve XIP. Thus, the reverse translation is:
<spid=IP1, dpid=HPID, spa=XPA, dpa=HPA> -X-> <sa=IP1, da=XIP>
Note that even though the Pip host does not transmit XIP in its
packet, it knows that XIP is the pool IP address assigned to it, and
uses XIP (and IP1) to calculate the TCP pseudo-header checksum.
Pip WG, Expires February 1, 1994 [Page 7]
INTERNET-DRAFT Pip Transition July 1993
2.4. Creating the Assignment
In this section, we discuss how the assignment XIP<->HPID is made and
communicated to the Pip host. We also discuss how the translating
router XR is discovered.
We are interested in the following cases:
Initiating Responding
Host (IH) Host (RH) Scope IH DNS RH DNS
---------- --------- ----- ------ ------
1. IP-only Pip Inter-domain IP-only Pip
2. Pip IP-only Inter-domain Pip IP-only
3. IP-only Pip Inter or Intra-domain Pip Pip
4. Pip IP-only Inter or Intra-domain Pip Pip
5. IP-only IP-only Inter-domain N/A N/A
6. IP-only IP-only Intra-domain N/A N/A
By initiating host, we mean the host that initiates the exchange of
packets (that is, first contacts DNS and sends the first IP/Pip
packet). Note that cases 5 and 6 imply two IP hosts communicating
across a Pip backbone infrastructure.
We assume that any domain with a Pip host has updated DNS. Any
domain with no Pip hosts may or may not have an updated DNS. If it
does, then we assume that it also has a translating router (XR) at
its border. Note that therefore Cases 1 and 2 don't apply to the
intra-domain case (where DNS must be Pip if any host is Pip).
Note that in all cases but 5, the Pip DNS systems discover XRs, thus
offloading the burden of XR discovery from XRs. Only case 5 requires
that an XR does an inverse DNS lookup to discover an XR. (Compared
with IPAE, where every new packet exchange from IP to IPng requires
such a lookup by the XR.)
Below we discuss each case.
2.4.1. Case 1.
Here, an IP host is initiating and a Pip host is responding. Only
the Pip host has Pip DNS.
Pip WG, Expires February 1, 1994 [Page 8]
INTERNET-DRAFT Pip Transition July 1993
a. The initiating IP host I-IP-H queries its local DNS server I-
IP-DNS.
b. I-IP-DNS queries the Pip host's DNS server R-Pip-DNS (assuming
that I-IP-DNS is not also the DNS server for the responding host
R-Pip-DNS). Based on the nature of the query, R-Pip-DNS knows
the initiating host I-IP-H to be IP-only [3].
c. Null step here to sync with the next section. Please ignore.
d. The R-Pip-DNS server must determine the translating router XR
for this exchange. At this point, R-Pip-DNS knows that I-IP-H's
domain has no XR's internally (or else it would have a Pip DNS),
but it doesn't know if there is an XR at the border of I-IP-H's
domain or not. R-Pip-DNS does not know the name or IP address
of I-IP-H. It only knows the IP address of I-IP-H's DNS server
I-IP-DNS. Using the IP address of I-IP-DNS as the inverse
domain name, R-Pip-DNS makes an inverse query to the set of sys-
tems that have been established to handle these inverse queries.
e. If there are one or more XRs at the border of I-IP-H's private
domain, then the inverse query returns the Pip ID and Pip
addresses of the XRs. If there isn't an XR at the border of I-
IP-H's private domain, then the inverse query returns null.
f. If the previous step returned null, then an XR bordering the Pip
host's private domain (or inside the Pip host's private domain,
if none have been installed at the border) is selected as the XR
for this exchange. If there are multiple XRs at the local
border, R-Pip-DNS chooses among them to be the XR for the
exchange. This choice may be based on knowledge of the host's
or domain's policies, or may be a pre-set preference, or may be
random. (These XRs are known through static configuration of
R-Pip-DNS.) If the inverse query did not return null, then one
of the XRs returned in the inverse query are selected.
g. The R-Pip-DNS now queries the XR for an assignment of a Pool
address XPA to the Pip host R-Pip-H. (Note that if the XR is
local to the Pip host's domain, this assignment may very well
have already been made. Never-the-less, the query is made.) The
query contains the Pip ID of R-Pip-H, plus other information
from DNS such as the Pip addresses, mobile host server, and so
on [3].
h. The XR makes the assignment XPA, and returns it to R-Pip-DNS.
Pip WG, Expires February 1, 1994 [Page 9]
INTERNET-DRAFT Pip Transition July 1993
i. R-Pip-DNS returns assigned IP address XPA to I-IP-DNS, which in
turn returns it to the IP host I-IP-H. (The Time-to-Live in the
response should be quite low, perhaps even 0.)
j. The I-IP-H sends an IP packet with it's IP address IPA as the
source address, and XPA as the destination address.
k. XR receives this packets, looks up the assignment using XPA,
retrieves the information about R-Pip-H, and creates a Pip
header to send to R-Pip-H. The source Pip ID of the header con-
tains IPA (in an Pip ID format that indicates that the host is
an IP-only host). The destination Pip ID is R-Pip-H's Pip ID.
The destination Pip address is R-Pip-H's Pip address. The
source Pip address is that of XR. Finally, there is an option
added that contains XPA. This is necessary for the Pip host to
be able to compute the pseudo-header checksum.
2.4.2. Case 2.
Here, a Pip host is initiating and an IP host is responding. Only
the Pip host has Pip DNS.
a. The initiating Pip host I-Pip-H queries its local DNS server I-
Pip-DNS.
b. I-Pip-DNS queries the IP host's DNS server R-IP-DNS. (It may
have been necessary for I-Pip-DNS to first determine that R-IP-
DNS is in fact an IP-only DNS server. This is part of DNS tran-
sition [3].)
c. I-Pip-DNS receives the IP address IPA of the IP host R-IP-H in
the answer.
d. I-Pip-DNS must determine the translating router XR for this
exchange. Using IPA as the inverse domain name, I-Pip-DNS makes
an inverse query to the set of systems that have been esta-
blished to handle these inverse queries.
e-f. These steps are the same in the previous section (but with I and
R reversed).
Pip WG, Expires February 1, 1994 [Page 10]
INTERNET-DRAFT Pip Transition July 1993
g. I-Pip-DNS returns the information about the XRs, along with R-
IP-H's IP address IPA, to I-Pip-H.
h. I-Pip-H determines which of the XRs is appropriate for this
packet exchange (see [4] for a description of how this is done).
i. I-Pip-H now queries the selected XR for an assignment of a Pool
address XPA for itself.
j. The XR makes the assignment XPA, and returns it to I-Pip-H.
k. I-Pip-H sends a Pip packet with a destination Pip ID containing
IPA (in an Pip ID format that indicates that the host is an IP-
only host). The source Pip ID is that of I-Pip-H. The destina-
tion Pip address is that of XR. The source Pip address is that
of I-Pip-H. The pseudo-header checksum is calculated using IPA
and XPA.
l. XR receives this packets, looks up the assignment using the Pip
host's Pip ID, retrieves the information about R-IP-H, and
creates a Pip header to send to R-IP-H. The source IP address
is XPA, and the destination IP address is IPA.
2.4.3. Case 3.
Here, an IP host is initiating and a Pip host is responding. Both of
the host's domains have Pip DNS.
a. The initiating IP host I-IP-H queries its local DNS server I-
Pip-DNS.
b. I-Pip-DNS queries R-Pip-H's server R-Pip-DNS. Because of the
nature of the query, R-Pip-DNS knows that I-Pip-DNS is a Pip
capable DNS machine, and that either 1) I-IP-H is in the same
domain as R-Pip-H, or 2) I-IP-H is in another domain, and it's
domain has an XR (either at its border or internally).
c. R-Pip-DNS returns the Pip information (Pip ID, Pip addresses,
etc.) of R-Pip-H to I-Pip-DNS.
d. I-Pip-DNS determines if R-Pip-H is intra- or inter-domain by
comparing R-Pip-H's Pip address against a local table indicating
Pip WG, Expires February 1, 1994 [Page 11]
INTERNET-DRAFT Pip Transition July 1993
which Pip address prefixes are intra-domain. This table must be
maintained by hand (though the consequence of not maintaining it
properly is a non-optimal path rather than failure to communi-
cate).
e. I-Pip-DNS knows that the order of preference for choosing the XR
is 1) choose one on I-IP-H's subnet, 2) choose the XR at I-IP-
H's domain's border (only if inter-domain), 3) choose the XR on
R-Pip-H's subnet (only if intra-domain), and 4) let R-Pip-H be
the XR (that is, R-Pip-H transmits and receives IP packets,
again, only for intra-domain). (Note that if option 4 happens,
the Pip host loses the ability to be mobile.)
f. I-Pip-DNS must therefore first determine if there is an XR on
the subnet of the IP host or not. To do this, I-Pip-DNS looks
in its local database, which has a listing of all IP subnets
with Pip routers on them. If an entry exists for I-IP-H's sub-
net, then the XR on that subnet is chosen (choice 1 in step e).
If not, but the communications is inter-domain, then the border
XR of I-IP-H's domain is used (choice 2 of step e). If the com-
munications is intra-domain, I-Pip-DNS determines if there is an
XR attached to R-Pip-H's subnet. This is done using the same
table accessed earlier in this step (except with the Pip Address
as the index instead of the IP address). (Except for very early
in transition, there will usually be an XR on R-Pip-H's subnet.)
If there isn't, then R-Pip-H must be the XR for itself. (This
will be the case where there is only a single host, or a small
number of hosts, and no router, on a given subnet. It means
that the first Pip system installed on a subnet must be given a
pool of IP addresses.)
g. I-Pip-DNS now queries the XR for an assignment of a Pool address
XPA to the Pip host R-Pip-H.
h. The XR makes the assignment, and returns it to I-Pip-DNS.
i. I-Pip-DNS returns assigned IP address XPA to the IP host I-IP-H.
j-k. These steps are the same as for Case 1.
2.4.4. Case 4.
Here, a Pip host is initiating and an IP host is responding. Both
Pip WG, Expires February 1, 1994 [Page 12]
INTERNET-DRAFT Pip Transition July 1993
hosts' domains have Pip DNS.
a. The initiating Pip host I-Pip-H queries its local DNS server I-
Pip-DNS.
b. I-Pip-DNS queries the IP host's DNS server R-Pip-DNS.
c. R-Pip-DNS determines if I-Pip-H is intra- or inter-domain. To
do this, R-Pip-DNS indexes the table discussed in step d of Case
3, using the Pip address or IP address (whatever is known) of
I-Pip-DNS. (The assumption here is that I-IP-H is in the same
domain as I-Pip-DNS.)
d. At this point, R-Pip-DNS must determine which XR should handle
this communications. This is done in the same way as done by
I-Pip-DNS in step f of Case 3.
e. Having determined the appropriate XRs, R-Pip-DNS returns infor-
mation about the XRs and the IP address of the IP host R-IP-H to
I-Pip-DNS, which forwards it on to I-Pip-H.
f. (Null step here to sync with Case 2. Please ignore.)
h-l. These steps are the same as for Case 2.
2.4.5. Case 5.
Here, an IP host is initiating and an IP host is responding. The two
IP hosts are in different domains. It is irrelevant if DNS is Pip or
IP.
a. The initiating IP host I-IP-H queries its local DNS server I-
DNS.
b. I-DNS queries the responding IP host's DNS server R-DNS,
receives the IP address of the responding IP host R-IP-H, and
returns it to I-IP-H. (Note that IP addresses must be globally
unique for this to work. At the point where IP addresses are
not globally unique, interdomain communications between IP-only
hosts might not be possible.)
Pip WG, Expires February 1, 1994 [Page 13]
INTERNET-DRAFT Pip Transition July 1993
c. I-IP-H transmits a packet with its IP address as the source
address, and R-IP-H's IP address as the destination address.
d. This packet reaches a translating router I-XR, either at the
border of I-IP-H's domain if inter-domain, or within the domain,
probably at I-IP-H's subnet router, otherwise. (If the infras-
tructure is IP, then the packet won't reach a translating router
and will be sent IP end to end.)
e. I-XR first determines if the packet is intra- or inter-domain.
Within a domain, each Pip router knows the mapping between each
Pip subnet address prefix and its corresponding IP subnet
number. This information is carried by the intra-domain routing
protocol. I-XR indexes the database carrying this information.
For this case, we assume inter-domain.
f. Because it is interdomain, I-XR must determine the Pip address
of the translating router R-XR, either at the border of R-IP-H's
domain, or on R-IP-H's subnet. This is done using the same
inverse query that was used for Cases 1 and 2, only here I-XR
initiates the query instead of <I or R>-Pip-DNS. Using the IP
address of I-IP-H as the inverse domain name, I-XR makes an
inverse query to the set of systems that have been established
to handle these inverse queries.
g. The inverse query returns the Pip ID and Pip addresses of R-XR
(for this case, there must be an XR at the border or within R-
IP-H's private domain). I-XR creates a data base entry relating
the IP address of R-IP-H with the Pip information for R-XR.
This is used to translate this and subsequent packets from I-
IP-H into Pip packets.
h. I-XR translates the IP packet into a Pip packet destined for R-
XR. The source Pip ID of the header contains the IP address of
I-IP-H (in an Pip ID format that indicates that the host is an
IP-only host). The destination Pip ID contains the IP address
of R-IP-H. The destination Pip address is R-XR's Pip address.
The source Pip address is that of I-XR.
i. When R-XR receives this packet, it creates a data base entry
relating the IP address of I-IP-H (taken from the source Pip ID)
with the Pip address of I-XR. This entry is used to translate
IP packets from R-IP-H. Note that subsequent packets from I-
IP-H and R-IP-H may go through different XRs (if there are more
than one at the border). In this case, the XRs receiving the
Pip WG, Expires February 1, 1994 [Page 14]
INTERNET-DRAFT Pip Transition July 1993
packets make inverse queries as described above.
2.4.6. Case 6.
Here, an IP host is initiating and an IP host is responding. The two
IP hosts are in the same domain. It is irrelevant if DNS is Pip or
IP.
a-e. These steps are the same as for Case 5, except with the outcome
that the two IP hosts are determined to be intra-domain.
f. Because it is intra-domain, I-XR does not need to determine the
Pip address of the translating router R-XR. Rather, since it
knows the mapping between R-IP-H's subnet number and the Pip
address of R-IP-H's subnet, it can generate a Pip header algo-
rithmically. I-XR translates the IP packet into a Pip packet
destined towards R-XR. The source Pip ID of the header contains
the IP address of I-IP-H (in an Pip ID format that indicates
that the host is an IP-only host). The destination Pip ID con-
tains the IP address of R-IP-H. The destination Pip address is
the Pip address of the subnet that corresponds to R-IP-H's IP
subnet address. The source Pip address is that of I-XR.
g. This packet will travel towards R-IP-H until it reaches an XR
that must translate the packet back into IP. The reverse trans-
lation is simple. The source and destination IP addresses are
copied over from the source and destination Pip IDs. The
resulting IP packet is routed towards R-IP-H.
h. Packets returning from R-IP-H to I-IP-H execute steps f and g.
2.5. Inverse Lookup Infrastructure
On several occasions, it is necessary for a DNS system or an XR to do
an inverse query on IP address searching for an XR for the destina-
tion IP host. These queries are handled by a hierarchy of DNS
servers installed for this purpose.
At the top of the hierarchy are a relatively small set (perhaps 10 or
so) of root servers. These root servers will be authoritative for
Pip WG, Expires February 1, 1994 [Page 15]
INTERNET-DRAFT Pip Transition July 1993
private IP domains that have not installed an Pip systems, but that
have an XR at the border. By authoritative, we mean that they will
hold the actual database entries that map IP addr/mask to XR informa-
tion. The root servers will contain pointers to lower level servers
for those private domains that have installed some Pip systems.
These lower level servers will be authoritative for the XRs in their
domain.
All servers will be capable of being both authoritative and pointing
to lower level servers. In addition, the entries will be keyed by
maskless IP addr/masks. Therefore, the number of hierarchy levels of
inverse query DNS servers is entirely determined by configuration.
As such, it will be possible in the future to add a layer of hierar-
chy below the root servers if they prove to be a bottleneck.
2.6. Configuration Requirements
Pip transition will start with a "seed" Pip backbone (the Pbone).
The Pbone will consist of a small number (10 to 20) of Pip routers
installed around the internet--preferably in places where the most
policy routing control can be leveraged, for instance, at DMZs. (DMZ
meaning so-called De-militarized zone, such as a FIX or a CIX.) There
will also be a seed system of inverse Pip-DNS lookup systems. Ini-
tially, these are likely to be the same machines as the Pbone
routers. As the Pbone routers (sparcs) are replaced by "real" Pip
routers, these systems can be dedicated to the inverse lookup func-
tion.
When the first host is installed in a private domain, Pip DNS must
also be installed, and preferably Pip routers should be installed at
the borders of the domain. If Pip routers are not installed at the
borders, then either a Pip router internal to the domain, or a router
outside the domain, must be used for translation. Using XRs not at
the border can weaken or prevent provider selection, and can result
in non-optimal paths (because the packet must be routed via the XR).
When Pip DNS is installed, it must be configured with the addresses
(IP or Pip) of higher level inverse DNS lookup servers (along with
all the other usual DNS configuration information). It must also be
configured with IP addr/masks showing which IP address prefixes are
within its private domain.
When the first Pip system is installed on a subnet, it should act as
Pip WG, Expires February 1, 1994 [Page 16]
INTERNET-DRAFT Pip Transition July 1993
a router, even though it may also be serving as a host. As a router,
it must be configured with information about its neighbor routers,
either those on directly connected subnets or those reachable through
IP, including the border routers. (Note that it is possible to
install a single host on a subnet and configure it with non-attached
routers over IP. This will likely be common very early in transi-
tion, especially during initial experimentation. Over time, however,
this should be the exception rather than the rule.)
As the first router on a subnet, it must also be configured with a
pool of IP addresses to handle Pip hosts on its attached subnets.
Note that the addresses in the pool are only used for intra-domain
communications. (Generally, border XRs handle translation for
inter-domain packets, though it is possible for an internal Pip
router to be the XR for inter-domain traffic before a border XR is
installed.) DNS must also be updated to indicate that a Pip router
has been installed on the subnet, with the mapping between Pip subnet
address and IP subnet address.
When an XR is installed at the border, it's neighbor routers must be
configured. It must also be configured with two pools of IP
addresses, one to serve IP hosts in the private domain (this can be a
re-used class A), and one to serve Pip hosts in the private domain
(these must be globally unique). Local Pip DNS, if it exists, must
be updated to have knowledge of the XR, and to know which IP prefixes
it serves. Root DNS inverse-lookup servers must be updated to know
that the local DNS handles these IP prefixes if local Pip DNS exists,
or must be configured with direct information about the border XR
otherwise.
References
[1] Dave Crocker, Bob Hinden, "IP Address Encapsulation (IPAE):
A Mechanism for Introducing a New IP", Internet Draft, Nov 1992.
[2] Kjeld Borch Egevang, Paul Francis, "The IP Network Address
Translator (NAT)", Internet Draft, May 1993
[3] Thomson, Francis, "Use of DNS with Pip", Internet-Draft
[4] Francis, "Pip Host Operation", Internet-Draft
Pip WG, Expires February 1, 1994 [Page 17]